…elete setup

The "Multi-Object Delete Success" beforeEach uploads 1000 objects behind what
looks like a concurrency limiter of 20. It is not one. objects.map() invokes all
1000 async calls synchronously; the first 20 push and the other 980 all park on
the same `await Promise.race(queued)`. When the first put settles they all wake,
and each splices one entry off the head of the queue regardless of whether that
entry had settled, so the queue empties, every waiter's `while` test goes false,
and the remaining puts fire together. Running the limiter against an
instrumented stub gives a peak of 999 concurrent puts against an intended 20.

That is the ServiceUnavailable seen in run 33681270087: a thousand simultaneous
puts, not twenty.

It also explains why one failure becomes seven. Promise.all rejects on the first
error while the other puts are still in flight, so the hook throws with writes
outstanding, and the bucket cannot be deleted. All four suites in this file
share the bucket name multi-object-delete-234-634, so once it is left behind
with objects in it, every later suite's cleanup fails with BucketNotEmpty --
which is exactly the shape of the run: one ServiceUnavailable followed by six
BucketNotEmpty.

Two changes, both already present on development/9.3 and newer in one form or
another:

- Replace the limiter with a fixed pool of 20 workers draining a shared queue.
  Concurrency is genuinely bounded and every put is settled before the hook
  returns, on the failure path too, so teardown can no longer race them.
- Empty the bucket before deleting it in all four cleanup hooks. The 9.3 line
  gained this in 9eb5777, but that commit is an aws-sdk v3 migration of the
  whole file and is not something to cherry-pick onto 9.2; this is the
  equivalent written for the v2 client, and nothing else from it.

Clears CLDSRV-992 row F10 (all seven failures).

Issue: CLDSRV-992